home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re ODF Observations < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  2.3 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF Observations
  2. Sent:        7/10/96 9:14 AM
  3. Received:    7/10/96 9:42 AM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >o My part has a lot of FW_CEditView's. It seemed rather difficult to get the
  9. >FW_CEditView's to reflect my part's contents and vice versa.  For example, 
  10. >when
  11. >I have multiple frames, I want the changes made to a FW_CEditView in one 
  12. >frame
  13. >to be immediately reflected in the other frames.  The default implementation,
  14. >i.e. the implementation based on the Hello part, just forced a redraw which
  15. >wouldn't do anything to propagate the newly typed text to the corresponding
  16. >FW_CEditView's.  My solution was to use the notification subsystem to 
  17. >notify the
  18. >frames to update the FW_CEditView's.  Is there a more general way to 
  19. >synchronize
  20. >frames and the content?
  21. >
  22. >o More notification classes would be useful, i.e. 
  23. >FW_CBecameTargetNotification,
  24. >FW_CResignedTargetNotification, FW_CEditViewChangedNotification, etc.
  25. >
  26.  
  27. We know about this problem and it is on our list of future features. View 
  28. synchronisation accross frames is a complex problem and we are looking at 
  29. different solutions.
  30.  
  31. >o I hate short file names. Alas, the cost of cross-platform code.
  32. >
  33. >o When is ODF 2 scheduled for release?
  34.  
  35. ODF 2 will be on the web early september
  36.  
  37. >
  38. >o It seems like it would be useful to be able to copy and assign content
  39. >objects.  For example, if you want to be able to undo a drop of a part of the
  40. >same type, a command class could just retain a copy of the content as the 
  41. >saved
  42. >data.  FW_Content lacks an explicit copy constructor and assignment operator.
  43. >The compiler generated versions look safe to use for the current class but 
  44. >that
  45. >is no guarantee that they will remain safe. Does it make sense to add an
  46. >explicit copy constructor and assignment operator?  Or should I use a
  47. >stream/archiving to duplicate the content's data?
  48. >
  49.  
  50. We will look into that.
  51.  
  52. ........................................................................
  53.  Henri Lamiraux                                      lamiraux@apple.com
  54.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  55. ........................................................................
  56.  
  57.  
  58.